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I claim: 



1 1 . A method for an automated banking system for permitting a customer of a 

2 bank to remotely authorize and request a computerized monetary transaction be 

3 made by their bank, said method comprising the steps of: 

4 providing a computerized system at the customer's location; 

5 • receiving on the customer's system, a customer's manually inputted request 

6 for the customer's bank to conduct a monetary transaction; 

7 automatically running on the customer's system, in response to a request a 

8 monetary transaction program for generating a properly formatted monetary 

9 transaction document as an intermediary document (IDOC); 

10 automatically retaining in the customer's system the IDOC in a remote 

1 1 function call (RFC) queue, for a predetermined period of time, to permit the IDOC to 

12 be passed into an eBanking interface server of the customer's system for further 

13 processing; 

14 programming said interface server to automatically convert the IDOC into an 

15 extensible markup language (XML) formatted document; 

16 automatically transferring over a computer network the XML formatted IDOC 

17 from the customer's system to a compatible eBanking server in the customer's bank; 

18 and 

19 automatically processing the requested monetary transaction via said server 

20 of said bank responding to the IDOC. 

1 2. The method of Claim 1 , further including the steps of: 
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2 automatically operating the bank's eBanking server to send an XML formatted 

3 status document to said customer; 

4 automatically receiving said status document on the customer's system; 

5 operating the customer's system to permit the customer to read the received 

6 status document; and 

7 automatically logging the received status document into a core transaction 

8 database memory in the customer's system. 

1 3. The method of Claim 1 , wherein said step of automatically running said 

2 monetary transaction program includes the steps of: 

3 entering parameters for the requested monetary transaction; 

4 creating a monetary transaction proposal; and 

5 executing a monetary transaction run to generate said IDOC. 

1 4. The method of Claim 1 , wherein said RFC queue retaining step includes the 

2 steps of: 

3 releasing the IDOC to the RFC destination of the eBanking server in the 

4 customer's bank; 

5 updating the IDOC status to a digitized code indicative of data being 

6 successfully passed to a port; 

7 executing the IDOC received at the port into an RFC queue; and 

8 checking to determine if a communication link to said server in the customer's 

9 bank is active or inactive. 
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1 5. The method of Claim 4, further including the steps oft 

2 responding to said interface server of said bank being inactive by increasing a 

3 number of retries counter by "1 "; 

4 determining if the number of retries is greater than a predetermined maximum 

5 number; and 

6 resubmitting the IDOC to the RFC queue if the number of retries does not 

7 exceed the maximum number and 

8 repeating said checking step. 

1 6. The method of Claim 5, further including the steps of. 

2 responding to the number of retries being greater than the predetermined 

3 number, by notifying troubleshooting personnel of a problem in establishing a 

4 communication link with said interface server of the bank; 

5 resubmitting the IDOC to the RFC queue in response to a communication that 

6 the linkage problem has been resolved; and 

7 repeating said checking step. 

1 7. The method of Claim 4, further including the steps of. 

2 responding to an active interface server by mapping the IDOC parameter 

3 fields to appropriate variables; 

4 storing IDOC data in an eBanking DB (database); 

5 updating the IDOC status to indicate acceptable translation; 

6 formatting the IDOC into instructions complying with a standard format 

7 implemented by the Society for Worldwide Data Bank Communication; 
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8 compiling the formatted IDOC and subsequent formatted IDOCs each into a 

9 transaction document formatted in extensible markup language (XML); 

10 retrieving bank specific parameters from an eBanking.CNF configuration file; 

1 1 creating a digital signature for each XML formatted document using client 

12 certificates; 

13 establishing a secure connection to the computer server in the customer's 

14 bank; 

15 determining whether a secure connection was successfully established; and 

16 responding to a successfully established secure connection by transferring 

17 over a computer network each transaction document containing transaction 

18 instructions and a digital signature to the computer server in the customer's bank. 

1 8. The method of Claim 7, further including the steps of. 

2 responding to a failure to establish a secure connection by logging the XML 

3 document along with bank specific parameters into a database labeled "Failed 

4 Services"; 

5 automatically retrying the successive steps of creating a digital signature, 

6 establishing a secure connection, and determining if a secure connection has been 

7 established; 

8 determining whether the number of retries is greater than a predetermined 

9 maximum number; and 

10 continuing said step of automatically retrying if the number of retries is not 

1 1 greater than the maximum number. 
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1 9. The method of Claim 8, further including the steps of: 

2 responding to the number of retries exceeding the maximum number, by 

3 updating the I DOC status to a code indicative of an error while posting payments; 

4 sending an e-mail notification to an authorized officer of customer for release 

5 of the payment via prior conventionally established telex or facsimile transmission; 

6 responding to the e-mail, the authorized officer releases or provides the 

7 monetary transaction documents via telex or facsimile to the bank; and 

8 updating an I DOC status code to indicate the monetary transaction successful 

9 completion has been acknowledged by the bank. 

1 1 0. The method of Claim 7, further including the steps oft 

2 waiting for a response over the computer network from the bank; 

3 receiving from the bank a response document formatted in XML containing 

4 response status codes and messages for each of the monetary payment instructions 

5 posted to the customer's bank; 

6 storing in an eBanking database the response document; 

7 processing the statuses in the response document for each of the associated 

8 monetary transactions instructions; and 

9 determining the status from the bank of each monetary transaction. 

1 11. The method Claim 1 0, wherein the step of determining the status of each 

2 monetary transaction includes the steps of: 

3 indicating a status code equivalent to "OK" for monetary transactions 

4 successfully processed by the bank; and 
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. 5 updating related I DOC statuses to have a code indicative of the bank having 

6 advised the monetary transaction was successfully made. 

1 12. The method of Claim 10, further including the steps oft 

2 indicating a status code corresponding to a Data Error causing the bank to 

3 reject the monetary transaction; and 

4 updating the IDOC status for the transaction to a code indicative of the 

5 transaction rejection due to a Data Error. 

1 1 3. The method of Claim 1 2, further including the steps of: 

2 sending an e-mail notification to an authorized officer of customer indicating 

3 the reason for rejection of the monetary transaction; 

4 determining by action of the authorized officer whether the rejection is valid; 

5 responding to a valid rejection by action of the authorized officer to use an 

6 eBanking transaction request to reverse the monetary transaction request; 

7 correcting via action of the authorized officer, the data that caused the bank to 

8 reject the monetary transaction; and 

9 reprocessing the corrected monetary transaction through said banking system 
10 for completion. 

1 14. The method of Claim 1 3, further including the steps oft 

2 responding to an invalid rejection by action of the authorized officer using 

3 appropriate eBanking transaction codes for releasing the monetary transaction via 

4 tested telex transmission to the bank; and 
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5 receiving via the customer's computer system an acknowledgment from the 

6 bank confirming completion of the monetary transaction. 

1 1 5. The method of Claim 1 0, further including the steps of. 

2 indicating a status code corresponding to "Failed" for the bank failing to 

3 complete the monetary transaction for unknown reasons; and 

4 updating in response to the "Failed" code the IDOC status to a code indicative 

5 of the failed monetary transaction. 

1 1 6. The method of Claim 1 5, further including the steps of 

2 sending via e-mail notification from the bank to the authorized officer the 

3 reasons for the failure by the bank to complete the monetary transaction; 

4 releasing by action of the authorized officer using an appropriate eBanking 

5 transaction code via tested telex or facsimile authorization to the bank to complete 

6 the monetary transaction; and 

7 receiving via telex or facsimile from the bank to the customer confirmation that 

8 the monetary transaction was completed. 

1 17. The method of Claim 10, further including the steps of 

2 indicating from the bank either a return status code corresponding to "DUDE" 

3 for a duplicate transmission by eBanking of a previous transmission rejected by the 

4 bank due to a Data Error, or corresponding to "DUOK" for a duplicate transmission 

5 by eBanking of a previous transmission successfully processed by the bank; 
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determining via the customer's computer system whether the return status 
code corresponds to DUDE or DUOK; 

determining in response to a status code of DUDE whether the last IDOC 
status for the monetary transaction is indicative of the transaction being rejected by 
the bank due to a Data Error; 

sending, in response to a rejection due to a Data Error, an e-mail notification 
to technical personnel for troubleshooting the reasons tine monetary transaction was 
posted in duplicate to the bank; and 

sending, in response to a rejection not being due to a Data Error, an e-mail 
notification to an authorized officer of customer to indicate reasons monetary 
transaction was rejected by bank. 



18. The method of Claim 17, further including the steps of: 

determining in response to a status code of "DUOK" whether the last IDOC 
status for the monetary transaction is indicative of successful processing of the 
transaction by the bank; 

changing the IDOC status to a code indicative of successful processing, in 
response to a No answer in the immediately previous determining step; and 

sending an e-mail notification to an authorized officer of customer and 
customer's technical personnel, in response to a Yes answer in the previous 
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9 associated determining step, for indicating the monetary transaction was duplicated 

10 in said automated banking system. 

1 1 9. The method of Claim 1 , further including the steps of. 

2 initiating, by action of the customer using a scheduler, a request for a bank 

3 statement; 

4 passing the request to said interface server of customer for conversion into an 

5 XML document; 

6 retrieving required parameters from an eBanking configuration file necessary 

7 to establish a secure socket layer (SSL) session over said computer network; 

8 establishing over said computer network a secure connection to the bank's 

9 eBanking server; 

10 determining if the connection is successfully established; 

11 determining in response to an unsuccessful connection whether a number of 

12 retries is greater than an allowed maximum number; 

13 repeating said secure connection establishing step in response to the number 

14 of retries not exceeding the maximum number; 

15 sending an e-mail, in response to the number of retries exceeding the 

16 maximum number, to an officer of customer and technical personnel to advise of the 

17 connection or statement retrieval failure; and 

18 raising a "Failure" exception to the scheduler for permitting a manual request 

1 9 for the statement 

1 20. The method of Claim 1 9, further including the steps oft 
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2 responding to a successful connection in said secure connection establishing 

3 step by posting the XML document containing statement request parameters to the 

4 bank's eBanking server; 

5 retrieving on customer's system statements) in XML formatted responses 

6 from the bank; 

7 storing both the XML formatted requests), and response(s), in an eBanking 

8 database of the customer, 

9 retrieving the statement(s) from the eBanking database to create a file in a 

10 designated folder; and 

1 1 reconciling the statements through use of standardized banking business 

12 software. 



1 21.. The method of Claim 1 , further including the steps of: 

2 initiating by action of the customer using an eBanking transaction code for 

3 requesting a statement showing the completed monetary transaction(s); 

4 converting, via said interface server of customer, the request into an XML 

5 formatted document; 

6 relieving required parameters from an eBanking configuration file necessary 

7 to establish a secure connection over the computer network to an eBanking server of 

8 the bank; 

9 establishing over said computer network a secure connection to the bank's 
10 eBanking server; 
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determining if the connection is successfully established; and 
responding to the unsuccessful establishment of the connection by returning a 
connection error message for display to the customer. 

22. The method of claim 21 , further including the steps of 

responding to the successful establishment of the connection by posting to 
the eBanking server of the bank the XML document containing the statement request 
parameters; 

receiving on the eBanking interface server of the customer a response from 
the bank of an XML formatted statement; and 

extracting the statement(s) for display to the customer. 
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1 23. An automated electronic banking system for initiating and automatically 

2 processing monetary transactions, said system comprising: 

3 initiating means for permitting a remotely located customer of a bank to 

4 selectively initiate a monetary transaction request for automated processing; 

5 a bank host server adapted for automatically receiving and processing 

6 said monetary transaction request; 

7 a computer network in data communication between said bank host 

8 server means and said initiating means, for transmitting the payment 

9 transaction request from the customer's initiating means to the bank host 

10 server; and 

11 interface means located between said initiating means and said 

12 computer network, for automatically interfacing the initiating means to the 

13 bank host server, and for converting said monetary transaction request into a 

14 readable form compatible with the bank host server. 



1 24. The system of Claim 23, further including: 

2 security means for establishing a secure transfer of data between said 

3 initiating means and said bank host server. 

1 25. The system of Claim 23, further including: 

2 programming means for operating said initiating means, interfacing 

3 means, and bank host server to automatically respond to said monetary 

4 transaction request, whereby said bank host server completes the monetary 

5 transaction, and insures the production of all necessary electronic records 
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detailing every necessary tracking step carried out in completing the payment 
transaction. 



1 26. The system of Claim 23, wherein said initiating means includes: 

2 at least one computer for permitting a customer to generate said 

3 monetary transaction request; 

4 a local computer server of customer connected between said at least 

5 one computer and said interfacing means; and 

6 a core transaction database memory for storing necessary computer 

7 programs for operating said local computer server, to respond to customer's 

8 monetary transaction request by preparing a monetary transaction order in the 

9 form of intermediary documents (I DOC), and all necessary tracking records 
10 for various associated payment parameters. 



1 27. The system of Claim 26, wherein said interfacing means includes: 

2 an interface computer server of customer connected between said 

3 local computer server and said computer network; and 

4 a core interface database memory for storing necessary computer 

5 programs for operating said interface computer server to convert 

6 communications from said local computer server into a format for 

7 communication over said computer network, and for storing said IDOCs, 

8 transaction documents, return codes, and messages related to transactions 
g with said bank host server means. 
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